Providing cellular connectivity for Machine-to-Machine Communication Equipments (M2MEs) is considered to be important because cellular systems such as UMTS are widely deployed and they provide improved coverage compared to the other wireless communication systems. M2MEs have different requirements from those of mobile handsets. In some case, it is possible for an owner of the M2MEs to manage M2MEs without any human intervention. There could be tighter requirements for M2MEs in terms of their hardware cost and size.
MCIM (Machine Communication Identity Module) is an identity module specifically designed for M2ME. MCIM is semantically the same as the existing identity modules such as USIM. However, MCIM is different from USIM in that the former is not necessarily stored and executed in a smartcard/UICC. MCIM can be stored and executed on different kinds of secure environment as far as the environment provides secure storage and secure execution environment. 3GPP is working on technologies and architectures for enabling flexible and efficient deployment of MCIMs to M2MEs. One of the architecture alternatives defined in 3GPP TR 33.812 allows downloading and provisioning MCIM on M2ME over-the-air. In such a remote subscription scenario, the M2ME first establishes initial connectivity to a mobile network operator called the Initial Connectivity Operator. The M2ME contacts a discovery server called the Discovery and Registration Function (DRF) with a special mobile operator called the Registration Operator (RO). Note that the M2ME is initially provisioned with credentials (i.e., IMSI and K) to connect to the Initial Connectivity Operator. The Registration Operator, when requested by the M2ME, provides information about the way to access a provisioning server called Download and Provisioning Function (DPF). The Registration Operator also selects mobile network operator (hereafter called the Selected Home Operator (SHO)) for the M2ME during the MCIM provisioning procedure. The SHO and the M2ME authenticate to each other. If authentication is successfully done, the MCIM to be assigned for the M2ME is provided by the SHO, and it is delivered to the M2ME through the Registration Operator (RO). After successful installation of MCIM, the M2ME attaches to the SHO using the MCIM to get operational PDN (Packet Data Network) connectivity. Note that in some deployment scenarios, a single operator can play the roles of the Initial Connectivity Operator (ICO) and the Registration Operator (RO).
The M2ME may change the home operator for various reasons. For instance, the M2ME may need to change operator when it is moved out of the coverage of the SHO. In case of home operator change, the M2ME needs to get PDN connectivity from the new SHO. More specifically, the PDN gateway (P-GW) of the new SHO will assign a new IP address to the M2ME.
Whenever the M2ME changes its home operator, a different IP address is assigned to the M2ME. Such an IP address change would cause disruption of communication if the M2ME is in the midst of communication with peers during the operation of home operator change. Even if there is no live communication with any peers during the operation of home operator change, it is not possible for the M2ME to be accessed by the peer unless there is a mechanism that informs the peer of M2ME's new IP address.
Dynamic DNS (DDNS) is considered to be a candidate solution for this problem, but there are some issues with DDNS. First, changes to DNS records do not propagate throughout the network immediately due to DNS cache servers. The DNS cache servers, which are commonly employed by ISPs today, store query results for a certain period of time. The peer cannot know the new IP address assigned to the M2ME until all the caches stored in the DNS cache servers expire and refresh after TTL. Second, DDNS cannot provide session continuity and live connections are to be aborted upon home operator change. For the above reasons, DDNS cannot be a complete solution for the problem.